Isn't Hex2num just parse(s, 16)?

Not quite — it's reinterpret(Float64, parse(UInt64, s, 16)).

I think a hypothetical parse(Float64, s, 16) would interpret a string without decimals like Float64(parse(Int64, s, 16)).

IMO reinterpret on a string is not the right function to use for this.

I'm also not convinced about reinterpret on a string, although it depends on the definition we give to reinterpret! I feel parse is also not the right function. Why not a new frombits function (does the inverse of bits) ?

Given #22088, is this still relevant?

Let's revive the useful non-num2hex parts of this.

Do we still need this one - or can we close?

As the other straightforward deprecation of num2hex/hex2num was chosen, I'm not sure what is the "useful non-num2hex parts of this" Jeff is refering to. I personally still wish the bitstring(x, hex) as another spelling of num2hex.

bitstring(x, 16) would be a perfectly ok spelling in my view, if you want to make a PR, but I have to say that I'm very strongly in favor of PRs that remove functions since we can always add methods to functions like bitstring in the future. What do you think the general rule would be for bases that don't have the property that the base divides the number of bits in x? Error? Pad with zeros to the length of the longest possible number of digits? I.e. length(bitstring(typemax(x), base)).